Create 20240508-computation-limit-hike.md #268
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Creating new draft FLIP
|
Issue created here to keep the FLIP tracker updated - #267 |
|
|
||
| Directly raising the computation limit entails substantial code modifications and collaboration with ecosystem developers. Alternatively, we can indirectly increase the limit by lowering the execution effort coefficients or weights (0.0239, 0.0123, 0.0117, and 43.2994 in the “execution effort” calculation). Decreasing these weights would effectively expand a transaction’s computation limit; in other words, more and larger operations would “fit within” the 9999 compute limit. | ||
|
|
||
| To determine the appropriate reduction factor for the weights, a thorough understanding of Flow’s execution capabilities in handling large transactions was necessary. This involved assessing how much “computation” could currently be accommodated in a block (on Mainnet24) and how much additional time a transaction could consume before encountering complications. For instance, if transactions in a block exceed the available block time (1.25s), they might need to be split across multiple blocks — a feature not currently supported; also, single transactions can never be split further. After evaluating these factors, it became apparent that increasing the transaction time by more than 5 times may lead to execution issues. Therefore, it is proposed to reduce the computation weights by a factor of 5. |
There was a problem hiding this comment.
Suggested change
| To determine the appropriate reduction factor for the weights, a thorough understanding of Flow’s execution capabilities in handling large transactions was necessary. This involved assessing how much “computation” could currently be accommodated in a block (on Mainnet24) and how much additional time a transaction could consume before encountering complications. For instance, if transactions in a block exceed the available block time (1.25s), they might need to be split across multiple blocks — a feature not currently supported; also, single transactions can never be split further. After evaluating these factors, it became apparent that increasing the transaction time by more than 5 times may lead to execution issues. Therefore, it is proposed to reduce the computation weights by a factor of 5. | |
| To determine the appropriate reduction factor for the weights, a thorough understanding of Flow’s execution capabilities in handling large transactions was necessary. This involved assessing how much “computation” could currently be accommodated in a block and how much additional time a transaction could consume before encountering complications. For instance, if transactions in a block exceed the available block time (1.25s), they might need to be split across multiple blocks — a feature not currently supported; also, single transactions can never be split further. After evaluating these factors, it became apparent that increasing the transaction time by more than 5 times may lead to execution issues. Therefore, it is proposed to reduce the computation weights by a factor of 5. |
There was a problem hiding this comment.
"before encountering complication" please can you elaborate in the text. The wording sounds very vague.
There was a problem hiding this comment.
Changed it a little bit - lmk how it sounds now
|
|
||
| The proposed/implemented changes aim to enhance the computation limit. For developers, the increase in effective computation limit along with the 5000:1 gas-to-compute ratio would empower them to execute larger contracts on EVM on Flow. The indirect method of increasing the compute limit (by changing the value of coefficients allowing larger transactions to “fit in”) eliminates any extra effort required to update their contracts for changes in the computation limit. Overall, this proposal would bring ‘EVM Equivalence’ in terms of contract and transaction size capabilities for EVM transactions on Flow. | ||
|
|
||
| ## Next Steps |
There was a problem hiding this comment.
Can you throw in some examples -
A token transfer would cost x in EVM gas and will use y in Cadence computation and will have a total transaction cost of Z FLOW.
There was a problem hiding this comment.
This FLIP proposes no alterations that affect the fees so don't think we should talk about the costs here. The fee adjustments would only result from the 100x transaction fee FLIP proposal and also from introducing EVMGasUsageCost * EVMGasUsage to the execution effort calculation (explained in this post - https://forum.flow.com/t/how-evm-transaction-fees-work-on-flow-previewnet/5751). This FLIP is not gathering feedback on either of those so any examples to showcase cadence vs EVM fees might be confusing. Additionally, any examples (like the one in the post shared) would solely be illustrative at this point and cannot be generalized at all, which might add to the confusion
Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com>
Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com>
Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com>
Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com>
Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com>
Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com>
Co-authored-by: Vishal <1117327+vishalchangrani@users.noreply.github.com>
vishalchangrani
approved these changes
May 16, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Creating new draft FLIP